The present invention concerns the deployment of an application from a first data processing means, such as a smart card, also referred to as a microcontroller card or an integrated circuit card, onto a second data processing means, such as a reception terminal for the smart card, in a wide-ranging and heterogeneous context. In this context, the application consists of software components dispersed in a telecommunication network and must be able to be executed from heterogeneous terminals having different hardware and software characteristics, such as a mobile radiotelephone terminal, a personal digital assistant and a personal computer. The heterogeneous terminals differ for example by their operating systems and their data coding and communication characteristics.
At present, users access various applications through telecommunication networks, in particular the Internet, almost using any terminal whatsoever amongst various heterogeneous terminals, from their offices, their homes, or public access terminals. Unfortunately, the applications are not capable of configuring themselves automatically according to characteristics personal to the user and it is necessary to reconfigure the terminal of the user according to the application chosen. In order to execute the applications correctly, the terminal must have service data available relating to the application to be executed and to the remote servers offering these applications, and confidential personal data, specific to each user and personalizing the access to one or more applications. When the users are sedentary, this information is generally static on their terminals. On the other hand, when the users are itinerant, the smart card offers an autonomous, secure and portable medium for supplying these data to the terminals the user is liable to need.
Furthermore, it is in the interest of application providers for their applications to be usable from a very large number of terminal types. An application must therefore be capable of adapting itself to the terminal in which it is executed. For example, a given application presents a complex window-based graphical interface in a personal computer, and simple textual menus in a mobile radiotelephone, or establishes audio or video communication according to the transmission speed offered by the network and the terminal.
The adaptability of distributed applications to their execution context and to the requirements of the user thus becomes a necessity (cf. the article entitled “Adaptability of applications for mobile users”, Michel Riveill et al., OCM'2000, Objets Composants Modéles, 8 May 2000). It is therefore necessary to deploy service applications according to the type of terminal and configuration personalisation for the user. This required flexibility is obtained through a modular architecture of each application. Each application is designed as a graph of components interconnected by connections. Deployment of the application onto a terminal creates therein instances of these components according to the personal characteristics and execution context.
As shown in FIGS. 1 and 2, definition of an application is known in a smart card CP, or any other portable electronic object having a relatively small memory capacity, by a descriptor DAP of an application AP identifying essential elements of the application such as the software components CA of the application and connections CX between these components in pairs. In general, an application comprises at least three components CA1, CA2 and CA3 and at least two connections CX1 and CX2 interconnecting the components CA1 to CA3 in pairs.
A component CA is a software processing unit encapsulating functionalities, small enough so that it can be created and maintained, and large enough so that it can be installed and supported. The component is provided with communication interfaces so that it can cooperate with other components and thus present its behavior to these other components. In practice, a software component can be physically located on any site whatsoever of a transmission network RT.
A connection defines the relationships between the communication interfaces of two components. Parameters of the connections of the application are also adapted to the context of the execution platform.
At the level of the smart card CP, an application descriptor DAP does not contain the element itself (software component CA or connection CX), but a descriptor DCA, DCX of the element CA, CX containing properties and parameters of the element defining it and making it possible to retrieve it from amongst a multitude of elements.
The properties of an element descriptor are fixed once and for all by the application provider who specialises the element, component or connection, in order to satisfy the requirements of the application and the user according to subscription characteristics for example. They indicate the characteristics of the platform on which the element can be executed, and the systems requirements necessary for its execution. One property can consist of an element address or type, which is associated with each element and used for searching for the code or the physical location of the element, or is intimately linked to the application or an application type. For example, the “account number” property is associated with a bank account manager component. These properties are, according to the prior art, fixed at the time of subscription to the service corresponding to the application by the user of the smart card, and are accessible for reading only.
Other properties, referred to as parameters, are preferably personalised by the user and can be modified at any time. For example, one parameter defines the currency for displaying an amount, or else a range of colours for displaying pages on a screen, or else again the value of the transmission speed or a transmission characteristic in a connection.
Each application descriptor is represented in the form of an object graph in an object-oriented language, for example JAVA (registered trademark) or XML (Extensible Markup Language).
The application descriptors DAP1, DAP2, DAP3 in a multi-application smart card are associated with the deployment driver (bootstrap) PI which constitutes within the smart card CP an application making it possible to select an application, configure it and deploy it according to its descriptor, after insertion of the card CP into the reception terminal TE. By gathering together the application descriptors and the deployment driver in the card, the confidentiality of the descriptors is ensured, with the result that the reading of the descriptors by the deployment driver does not require authentication. On the other hand, the deployment driver authenticates each client that interrogates it before making available to it all the application descriptors stored in the card. The driver PI can thus process one or more application deployments.
As already said, an application element, component or connection, is configured according to the application context, that is to say the hardware and software properties of the platform where the application will be executed, and parameters chosen by the user and personalizing the application. All this information is gathered together in the application element descriptor in order that the deployment driver PI filters the information contained in the element descriptor according to the application context and the personalisation parameters of the user.
The deployment driver PI located in the smart card CP transmits deployment commands to a deployment portal PO which is an application element implemented in the reception terminal TE. The main function of the portal is to receive the deployment commands and retransmit them to the execution platform in order to install the selected application. Thus the deployment portal principally has a function of informing the smart card about the environment in which the installation and execution of the selected application must be carried out, and a function of communicating with the card in order to receive various deployment commands for the selected application.
According to the prior art, the deployment of an application is synchronous, that is to say the commands produced by the deployment driver PI are transmitted sequentially, one after another, respectively for installing the elements of the application, then for parameterising the elements of the application, each command having to be acknowledged by the deployment portal PO on the terminal before the next command is sent by the driver PI.
Finally, when all the components and connections of the selected application AP are installed and parameterised, the application thus deployed is adapted to the terminal TE and can then be executed. The application is started by an execution command (RUN) which contains the name of the component of the selected application determining the entry point of the application, generally a user interface component.
It turns out that such a synchronous deployment has the drawback of making the installation of an application long, because of the succession of commands that must be acknowledged according to a predetermined scheme. This installation becomes longer as the number of components to be installed increases and the installation of said components necessitates calling upon the resources of the transmission network RT. This time during which the user is waiting can be a factor for rejecting an application when it is too great.
To attempt to remedy this drawback, a proposal has been made to perform the deployment of an application asynchronously, that is to say the driver PI requests the installation in parallel of all the application components which are independent of other components, without waiting for an acknowledgement from the portal PO, and then orders in parallel the installation of dependent elements in response respectively to acknowledgement of the installation of the elements on which they depend. Parameterising of the elements can also be performed asynchronously. In the case of a single-processor system, the execution in parallel of a number of processes means simply that a number of processes can be in the course of execution simultaneously, the resources of the processor being, of course, allocated to a single process at a given instant.
This solution makes it possible to optimise the use of the processing power and transmission speed offered by the terminal and transmission network. However, in particular when the application to be installed comprises many components and the deployment terminal has a small processing capacity, asynchronous deployment does not make it possible to significantly reduce the waiting time of the user before the application is started.
In the two preceding cases, all the application components are installed, even those that the user rarely or never uses, which unnecessarily increases the application installation time and unnecessarily overloads the resources of the terminal.